InfoMagic Internet Tools 1995 April/Internet Tools.iso/dos_win/winsock/maillist/94-04.Z/94-04/text0012.txt

Text File | 1994-04-30 | 13.0 KB | 322 lines

WSARCHIE 0.2 has been released and uploaded to these two sites:

ftp.demon.co.uk:/pub/ibmpc/winsock/apps/wsarchie/wsarchie.zip (should be
    renamed to wsarch02.zip.
ftp.sunet.se:/pub/pc/windows/wsarchie/wsarch02.zip

There is a text file alongside these detailing the main changes. Briefly these
are:

1.  WSARCHIE now uses port 1525 and not 901. This should help some of the people
    using wsarchie from behind firewalls.

2.  The niceness level has been set to 0. It was 32000+ which meant that it was
    asking for the worst service!

3.  The ini file can now reside in either the c:\windows directory or the
    working directory.

The next priority as regards further work is looking into problems occuring
when people have archie servers very close by. It would appear that wsarchie
is not able to get ready to receive fast enough! (I work down a dial up line
so this might be difficult for me to solve though).

Thank you for your interest and responses. If you have difficulties with this
version, have patience, let me know what they are and tell me what winsock you
use at the minimum. My email address is [e-mail].

David Woakes
--
---------------------------------------------------------------------------
David Woakes                               Voice: [phone]
8 Maxwell St                               Email: [e-mail]
Edinburgh
Scotland
From [e-mail] Thu Mar 31 17:13:57 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA01667; Thu, 31 Mar 1994 15:12:52 -0500
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
          id AA09271; Thu, 31 Mar 1994 14:44:53 -0500
Received: from GATEWAY by bigblue with netnews
    for [e-mail] ([e-mail])
To: [e-mail]
Date: 31 Mar 1994 17:13:57 GMT
From: [e-mail] (Darryl Friesen)
Message-Id: <2nf0cl$[e-mail]>
Organization: University of Saskatchewan
Sender: ses
References: <2ncu7u$[e-mail]>, <slawek.765069978@aries>
Subject: Re: Problems with new MS TCP-32 and WFW 3.11

On 30 Mar 94 23:26:18 GMT Slawomir Z. Janicki ([e-mail]) wrote:
> [e-mail] (Darryl Friesen) writes:

> >Has anyone else experienced probems with Micosoft's new TCP/IP
> >stack (the March beta) and Winsock apps?

[snip snip]

> >WinQVT/Net "drops" characters VERY frequently.  A look at the
> >console shows hundreds of errors, almost all are:

> >comm_write_char; send() error 10036
> >comm_read; recv() error 10036
> >comm_write_blk; send error 10036

> These symptoms would indicate incorrect setup. MS TCP/IP-32 works
> even with the incorrect mask/gateway/IP number but is just that:
> slow and erratic. Double check your setup and consult your admin.

I checked, double checked, then checked again.  I'm using the same
settings for name servers, gateway, net mask, and my IP address that
I have always used for DOS and Winsock apps.  Still no luck with
HGopher or Mosaic. (could it be related to the lack of DNS support
in this version?)

Bob Fenchel sent me a 'fix' for the WinQVT/Net problem though.
Changing the "dispatch=sync" to "dispatch=async" in the QVTNET.INI
file eliminates the problem of QVTNET 'dropping' characters (thanx
alot Bob!)

Anyone have any other suggestions?  Would it help if I posted my
config files (I always hate doing that because it wastes so much
bandwidth)?  I've received two other messages from people with
the same, or similar problems.

> Slawek Janicki
> [e-mail]

Thanx for the suggestion Slawek,

- Darryl

  ----------------------------------------------------------------------
   Darryl Friesen, Client Services              [e-mail]
   Department of Computing Services          University of Saskatchewan
   <A HREF="http://gopher.usask.ca/~friesend/">This is my Home Page</A>
  ----------------------------------------------------------------------
  "Time flies like an arrow, but fruit flies like a banana"
From [e-mail] Thu Mar 31 17:52:06 1994
Received: from bigblue.oit.unc.edu by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA01705; Thu, 31 Mar 1994 15:13:06 -0500
Received: by bigblue.oit.unc.edu (AIX 3.2/UCB 5.64/4.03)
          id AA06096; Thu, 31 Mar 1994 15:08:43 -0500
Received: from GATEWAY by bigblue with netnews
    for [e-mail] ([e-mail])
To: [e-mail]
Date: Thu, 31 Mar 1994 17:52:06 GMT
From: [e-mail] (Gary Hall)
Message-Id: <[e-mail]>
Organization: Simon Fraser University
Sender: ses
Subject: Problem recv()'ing with Novell Winsock

Hello there,
  I would like feedback about whether the following behaviour represents
a problem with the (Novell) Winsock.DLL I am using or with some error or
other in its use.

  In this application, (sx_msg) structures (see typedef below) are being passed
among processes running in the Unix and Windows environments. The structures
are 1076 bytes in length. The Winsock.DLL recv()'s messages arriving from the
Unix domain in two steps: the first is 1024 bytes long, the second is 52
bytes long. Although there is no problem with accessing the contents of the
first (1024 byte) portion of the message, the contents of the second are
apparently lost. There is no problem exchanging messages among processes within
the Unix domain.

  Here is an example of the debugging output produced by the receive_data
function whose definition appears following the example.  (For purposes of
debugging, '^' chars are substituted for '\0' chars and the final char in the
msg is set to null.) This is the message sent by the Unix process:

^^^tuNa^^^/^^^^SELECT A.S_DATE "Date", C.LOCATION_DESC "Location", B.OUTAGE_DESC "Out Type", A.OUTAGES "# of Outages" FROM ACMSREL A, RFOUTAGES B, RFLOCATIONS C WHERE A.OUTAGE_CODE = B.OUTAGE_CODE AND A.LOCATION = C.LOCATION AND A.S_DATE = (SELECT MAX(DISTINCT D.S_DATE) FROM ACMSREL D) AND A.LOCATION IN (2700, 2710, 2720, 2730, 2740, 2800, 6300) ORDER BY A.S_DATE, C.REF_NO, B.OUTAGE_DESC ^fs rw,bg,hard,intr,dev=8204 0 0
monoceros:/sx1 /sx1 nfs rw,bg,hard,intr,dev=8203 0 0
monoceros:/sx /sx nfs rw,bg,hard,intr,dev=8205 0 0
monoceros:/sx1 /sx1 nfs rw,bg,hard,intr,dev=8206 0 0
monoceros:/usr/lisp-4.0 /usr/lisp-4.0 nfs rw,bg,hard,intr,dev=8207 0 0
monoceros:/usr/spe-1.2 /usr/spe-1.2 nfs rw,bg,hard,intr,dev=8208 0 0
monoceros:/usr/lisp-4.0 /usr/lisp-4.0 nfs rw,bg,hard,intr,dev=8209 0 0
monoceros:/usr/spe-1.2 /usr/spe-1.2 nfs rw,bg,hard,intr,dev=820a 0 0
dipper:/home/dk2 /amd/dipper/home/dk2 nfs rw,dev=820e 0 0
apus:/home/dk5 /amd/apus/home/dk5 nfs rw,dev=820b 0 0
aquila:/am_link/local2.cs.sun4 /amd/aquila/net/local2 nfs rw,dev=8SYSTEMX/INTERFACE@RCI^l-rscn /am^^^

(The stuff between the SQL and the login string "SYSTEMX/INTERFACE@RCI" is
junk that happened to be in the memory allocated to the message.)

The receive_data function reports that 1024 bytes are retrieved the
first time thru the loop and prints out the first portion of the message:

^^^IuNa^^^/^^^^SELECT A.S_DATE "Date", C.LOCATION_DESC "Location", B.OUTAGE_DESC "Out Type", A.OUTAGES "# of Outages" FROM ACMSREL A, RFOUTAGES B, RFLOCATIONS C WHERE A.OUTAGE_CODE = B.OUTAGE_CODE AND A.LOCATION = C.LOCATION AND A.S_DATE = (SELECT MAX(DISTINCT D.S_DATE) FROM ACMSREL D) AND A.LOCATION IN (2700, 2710, 2720, 2730, 2740, 2800, 6300) ORDER BY A.S_DATE, C.REF_NO, B.OUTAGE_DESC ^fs rw,bg,hard,intr,dev=8204 0 0
monoceros:/sx1 /sx1 nfs rw,bg,hard,intr,dev=8203 0 0
monoceros:/sx /sx nfs rw,bg,hard,intr,dev=8205 0 0
monoceros:/sx1 /sx1 nfs rw,bg,hard,intr,dev=8206 0 0
monoceros:/usr/lisp-4.0 /usr/lisp-4.0 nfs rw,bg,hard,intr,dev=8207 0 0
monoceros:/usr/spe-1.2 /usr/spe-1.2 nfs rw,bg,hard,intr,dev=8208 0 0
monoceros:/usr/lisp-4.0 /usr/lisp-4.0 nfs rw,bg,hard,intr,dev=8209 0 0
monoceros:/usr/spe-1.2 /usr/spe-1.2 nfs rw,bg,hard,intr,dev=820a 0 0
dipper:/home/dk2 /amd/dipper/home/dk2 nfs rw,dev=820e 0 0
apus:/home/dk5 /amd/apus/home/dk5 nfs rw,dev=820b 0 0
aquila:/am_link/local2.cs.sun4 /amd/aquila/net/lo

The next time through 52 bytes are read. However, the printout of the package
is empty!

The size of the entire received message in this case is reported to be 1024,
and, when the entire message is displayed following exit from the loop
(code not shown in function definition below), it ends at the end of the first
retrieved portion. In other cases, when messages are received from another
server, the received message size is reported to be 1075 (final byte of
message is set to null); although in this case too the printout of the second
package is empty, not filled with '^'s or garbage as one would expect.

Finally, after the '^' chars have been replaced with '\0' chars, the message
type and SQL print out with no problem, but the login string is not there.

I would appreciate any thoughts or suggestions as to how to deal with this.

Gary Hall                  | Voice [phone] | INTERNET: [e-mail]
Centre for Systems Science | Fax   [phone] |
Simon Fraser University    |
Burnaby, B.C.  V5A 1S6     |

/****************** RECEIVE_DATA **********************************/

int FAR PASCAL receive_data (SOCKET sock, sx_msg FAR *theData)
{
  int           rval;
  int           err_no;
  int           write_pos = 0;
  int           count = sizeof (sx_msg);
  char     FAR    *package;
  do
    {
      rval = recv (sock, (char FAR *) &theData[write_pos], count, NULL);

    /* Print package size */
    wsprintf(szBuffer, "Size = %d ", rval) ;
    MessageBox (NULL, szBuffer, "Package!", MB_OK) ;

    /* Print package */
    if (write_pos == 0) { /* insert null in final byte of first package */
        package[rval - 1] = '\0';
    }
    wsprintf(szBuffer, "%s", package ) ;
    MessageBox (NULL, szBuffer, "Package!", MB_OK) ;
    if (write_pos == 0) {
        package[rval - 1] = '^';
    }

      if (rval < 0)
        {
      err_no = WSAGetLastError();
          if (err_no == WSAEWOULDBLOCK)
        continue;
      /* fi */

      wsprintf (szBuffer, "Error %d receiving message", err_no) ;
          MessageBox (NULL, szBuffer, "Wonderful!", MB_OK) ;
      return (SOCK_READ_FAILED);
        }
      /* fi */

      if (rval == 0)
        {
          wsprintf (szBuffer, "Read from closed communication channel") ;
          MessageBox (NULL, szBuffer, "Wonderful!", MB_OK) ;
          return (SOCK_READ_DISCONN);
        }
      /* fi */

      count -= rval;
      write_pos += rval;

    } while (count > 0);

    /* Print message size */
    wsprintf(szBuffer, "Received message size = %d ", _fstrlen((char FAR *)theData)) ;
    MessageBox (NULL, szBuffer, "Message!", MB_OK) ;

    return_nulls(theData);

      if (ntohl(theData->msg_type) == SQLSTRING) {
     wsprintf(szBuffer, "TYPE: %lu",ntohl(theData->msg_type)) ;
     MessageBox (NULL, szBuffer, "receive_data: IACF DLL", MB_OK) ;
     wsprintf(szBuffer, "SQL: %s",theData->u.orasql.sql) ;
     MessageBox (NULL, szBuffer, "receive_data: IACF DLL", MB_OK) ;
     wsprintf(szBuffer, "LOGIN: %s",theData->u.orasql.login_str) ;
     MessageBox (NULL, szBuffer, "receive_data: IACF DLL", MB_OK) ;
     }
  return (SOCK_NOERROR);
}

/*end receive_data*/


/*--- Typedefs --------------------------------------------------------------*/

/*
 * SQL query to Oracle structure
 */
typedef struct oracle_sql_query {
    char    sql[1024];        /* SQL statement */
    char    login_str[32];        /* account_name/password@db_string */
    long    header_flag;        /* include headers in output or not */
} orasql_query;

    .
    .
    .

typedef struct sx_message {
    long    msg_type;        /* message type */
    long    sender;            /*  */
    long    str_len;        /* length of string in union */
    long    flag;
  union u_data {
        long        numvalue;        /* numerical value */
        char        string[1024];        /* char string */
        char        strarray[16][64];    /* char string array */
        orasql_query    orasql;            /* SQL query to Oracle*/
        confirmwin    cwin;            /* confirm window */
        booleanwin    bwin;            /* two choice window */
        textwin        twin;            /* mult. input window */
        registration    reg;            /* server registration*/
    } u;
} sx_msg;



--
Gary Hall                  | Voice [phone] | INTERNET: [e-mail]
Centre for Systems Science | Fax   [phone] |
Simon Fraser University    |
Burnaby, B.C.  V5A 1S6     |
From [e-mail] Thu Mar 31 15:42:40 1994
Received: from MIT.EDU (MIT.MIT.EDU) by SunSITE.Unc.EDU (5.65c+IDA/FvK-1.07) with SMTP
          id AA05545; Thu, 31 Mar 1994 15:42:40 -0500
Received: from ASHPOOL.MIT.EDU by MIT.EDU with SMTP
    id AA05976; Thu, 31 Mar 94 15:42:23 EST
Message-Id: <[e-mail]>
To: [e-mail] (Chris A. Shenefiel)
Cc: Multiple recipients of list <[e-mail]>, [e-mail]
Subject: Re: Whois client for Winsock?
Date: Thu, 31 Mar 94 15:42:18
From: [e-mail]


>Does anyone know of a whois client for winsock?

A winsock version of a whois client is available via anonymous ftp from:

net-dist.mit.edu:/pub/dos/potluck/winsock/winwhois.zip

The zip file includes the source and executable. This has only been tested
on Novell's LWP winsock stack at this point. Please submit code changes or
bug reports to [e-mail].

Please note that there is also a LAN WorkPlace specific, i.e. not winsock,
client available at net-dist.mit.edu:/pub/dos/potluck/whois.exe